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Abstract 

This paper defines a simple guarded-command-like language and its semantics. 
The language is used as an intermediate language in generating verification condi- 
tions for Java. The paper discusses why it is a good idea to generate verification 
conditions via an intermediate language, rather than directly. 
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0 Introduction 

It is well-known that the later a software error is detected, the more expensive it is 
to correct. The Extended Static Checker for Java (ESC/Java) is a tool for finding, by 
static analysis, common programming errors normally not detected until run-time, if 
ever [3]. ESC/Java takes as input a Java program, possibly including user annotations, 
and produces as output a list of warnings of potential errors. It does so by deriving a 
verification condition for each routine (method or constructor), passing these verification 
conditions to an automatic theorem-prover, and post-processing the prover's output to 
produce warnings from failed proofs. 

Deriving verification conditions for a practical language, rather than for a toy lan- 
guage, can be complex. Furthermore, in designing a tool for automatic checking, one 
faces trade-offs involving the frequency of spurious warnings, the frequency of missed 
errors, the efficiency of the tool, and the effort required to annotate programs. To explore 
and exploit these trade-offs flexibly, it must be easy to change the verification conditions 
generated by the tool. 

To manage the complexity and achieve flexibility, we chose to derive verification 
conditions by first translating the source language into a simple intermediate guarded- 
command language, and then using the semantics of this guarded-command language to 
produce verification conditions. In this paper, we describe our intermediate language, 
give its semantics, and discuss how it is used in our tool. 

1 Translation stages 

Our translation from Java to verification conditions is broken into three stages. First, we 
translate from Java to a sugared form of our guarded-command language that includes 
high-level features such as iteration and method invocation. Second, we desugar the 
sugared guarded commands into primitive guarded commands. Finally, we compute 
verification conditions from these primitive guarded commands. 
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In the translation from Java into sugared guarded commands, we eliminate many 
of the complexities found in Java, such as switch statements and expressions with 
side effects. This part of the translation is bulky and tedious. We have designed the 
sugared guarded-command language to make the translation easy to understand and to 
implement. At the same time, this part of the translation is relatively stable. We find it 
nice to separate this bulky but stable part of the translation process from other parts that 
change during experimentation. 

The desugaring into primitive guarded commands is where we need a lot of flexibil- 
ity. This is the principal stage of the translation where we make the kinds of trade-offs 
mentioned in the introduction. In section 3, we give examples of how different desugar- 
ings, possibly chosen under user control, result in different kinds of checking. 

The semantics of the primitive guarded-command language is quite simple. Indeed, 
a naive set of equations for deriving verification conditions from primitive guarded com- 
mands fills less than half a page. However, by experimenting with different, but seman- 
tically equivalent, equations, we have achieved significant performance gains. Because 
this stage of the translation begins with such a simple language, we have been able to 
perform these experiments easily. 

2 Primitive guarded-command language 

Our primitive guarded-command language is a form of Dijkstra's guarded commands [2], 
with several important distinguishing features: exceptions [0, 6], partial commands [8, 
7], and going wrong (see, e.g., section 6.2 of [4]). (By including partial commands, we 
no longer need the "guards" that originally gave the language its name.) The syntax of 
commands in our guarded-command language is as follows: 

cmd ::= 

variable = expr | skip | raise | assert expr | assume expr 
| var variable* in cmd end | cmd ; cmd | cmd ! cmd | cmd D cmd 

where an expr is an expression in untyped first-order predicate calculus extended with 
labels. A labeled expression (label L : e) is semantically equivalent to the expression 
e , but supplies the label L to the theorem-prover in order to facilitate the production of 
user-sensible warning messages (see section 6 of [1], which describes an extended static 
checker for Modula-3). 

We model Java instance fields as maps from objects to values. Thus, we translate 
the Java expression o . f into selectif, o) , where the select function extracts from map 
/ the component indexed by o . 
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Unlike Dijkstra's guarded commands, our commands can terminate not only nor- 
mally, but also exceptionally and erroneously. We use exceptional termination to model 
Java's exceptions and also Java's control-transfer statements break, continue, and 
return. We use erroneous termination ("going wrong") to model violations of the 
programming discipline that ESC/Java checks. 

The semantics of our primitive guarded commands is given by their weakest liberal 
preconditions. For any command C and predicates (on the post-state of C) N, X, 
and W , the predicate wlp.C.(N, X, W) holds in exactly those initial states from which 
each execution of C either terminates normally in a state satisfying N , terminates ex- 
ceptionally in a state satisfying X , or terminates erroneously in a state satisfying W (or 
doesn't terminate at all, but all of our primitive commands do terminate). We define wlp 
by the following equations: 



wlp.(v= e).(N,X,W) - N[v*-e] 

wlp. skip. (N,X, W) = N 

wlp.raise.(N,X,W) = X 

wlp. (assert e).(N, X, W) = (e A N) v A W) 

wlp. (assume e).(N,X, W) = e^N 



wlp.(var vj . . . v n in C end). (AT, X,W) = ( V Vl . . . v n > wlp.C.(N, X, W) ) 



where in the equation for the var command, v\ . . .v n are distinct variables not occur- 
ring free in Af , X , or W . 

The verification condition for a routine r has the form 

BP =>• wlp. C. (true, true, false) 

where C is the translation of r and BP is the background predicate. The background 
predicate is a set of axioms, derived in part from declarations in the user's program, 
that encode various properties guaranteed by Java, such as properties of the type system 
(see [5] for the background predicate of a simple object-oriented language). 

3 Sugared guarded-command language 

At the outset of our project, we considered it fairly obvious that trying to expand Java 
directly into verification conditions would result in a software engineering disaster. In- 
troducing a desugaring stage was a less obvious design decision, but one that has turned 



wlp.(C0 ; C1).(N,X, W) 
wlp.(C0 ! Cl).(N,X, W) 
wlp.(C0 D Cl).(N,X, W) 



wlp.CO.(wlp.C\.(N,X, W),X, W) 
wlp.C0.(N, wlp.C\.{N, X, W), W) 
wlp.C0.(N, X, W) A wlp.C\.(N, X, W) 
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out to be valuable in managing complexity and maximizing flexibility. In this section, 
we give examples of constructs in our sugared language. 

Checks. To achieve a flexible treatment of conditions such a null dereferences, we 
use a command called check . For example, a Java statement v = o . f ; on line 27 
translates into the sugared commands 

check Null, 27, o != null ; 
v = selectif, o) 

We have several choices in the desugaring of the check command. If we want treat null 
dereferences as errors, then we desugar the check command into 

assert (label Null® 27 : o != null) 

ESC/Java lets users suppress null dereference warnings, either selectively or globally. If 
null dereference warnings are suppressed on line 27, then the check command desugars 
into 

assume o != null 

Introducing this assumption (instead of, say, desugaring the check command into skip ) 
prevents ESC/Java from, for example, generating a warning on line 28 if that line con- 
tains the dereference o . g. (But there are other cases where we do desugar a check into 
skip .) 

ESC/Java enforces a programming discipline in which null dereferences are consid- 
ered to be errors. If we wanted to support a programming style in which the programmer 
might intentionally dereference null and then handle the resulting Java exception, we 
would desugar the check command into something like 

(assume o == null ; . . . ; raise) D assume o != null 

where the " . . . " elides the commands that make the subsequent raise model the raising 
of a new NullPointerException . 

Loops. The translation of Java while, do, and for loops produces commands that 
contain a sugared command of the form 

loop { invariant / } C end 

In contrast to exiting the loop when C can no longer be executed [8], control exits this 
loop when C raises an exception. The usual way of defining wlp for loops involves a 
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strongest fixed point. We approximate this fixed point by considering only executions 
that iterate at most once. That is, we desugar the loop command into 

check Looplnvlnit, loc, J ; 
C; 

check LoopInvMaintained, loc, J ; 
assume false 

where loc is the source code location of the Java loop statement. While this approx- 
imation is coarse, we have found that it still allows the checker to find many program 
errors, even when J is the trivial invariant true (see section 9 of [1]). By translating 
Java loops into commands that contain loop commands, we retain the flexibility to try 
different desugarings. For example, we could unroll a loop two or more times. Or, we 
could produce a conservative desugaring of the form 

check Looplnvlnit, loc, J ; assume false 

D 

. . . ; assume J ; C ; check LoopInvMaintained, loc, J ; assume false 

where the " . . . " assigns arbitrary values to the assignment targets of the loop. Lastly, 
note that our translation retains the flexibility of strengthening any programmer-declared 
invariant with any kind of inferred invariants, for which the literature offers numerous 
techniques. 

Calls. Our sugared language also contains a call command, whose desugaring de- 
pends on the specification of the routine being called. Roughly speaking, call r{ eO, e\ ) , 
where routine r is allowed to modify x , desugars into a command of the form 

var pO p\ in 

pO = eO ; p\ = e\ ; check . . .preconditions . . . ; 
var xq in x 0 = x ; modify x ; assume . . . postconditions . . . end ; . . . 
end 

where modify x is a sugared command that desugars into 
var x 1 in x = x' end 

The actual desugaring of call is more complicated. For example, result values and 
exceptions must be treated, and postconditions include both user-declared conditions 
and conditions guaranteed by Java. 
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The modify command uses the nondeterminism inherent in the primitive var com- 
mand. In the desugaring of call (and also elsewhere in our translation), we use assume 
commands to restrict that nondeterminism. (Our translation uses the nondeterminism 
only of the var command, never of the D command. Whenever our translation gen- 
erates a D command, the enabling conditions of the subcommands are mutually exclu- 
sive.) 

4 Conclusions 

Generating verification conditions for a real-world language like Java is a significant 
engineering challenge. Such languages provide many programmer conveniences that 
make the derivation bulky and tedious. Also, finding the right derivation is as much an 
art as a science, an art involving much trial- and-error. Thus, it is important to appro- 
priately separate concerns both to manage complexity and to maximize flexibility. In 
building the ESC/Java verification condition generator, we have applied this principle in 
decomposing the verification condition generation into a three-stage process that seems 
to have served us well. 

History and acknowledgements. ESC/Java was built by Cormac Flanagan, Mark Lil- 
libridge, Greg Nelson, and the authors. Greg Nelson first suggested verification condi- 
tion generation via guarded commands, almost a decade ago. Subsequently, this be- 
came the basis for the ESC/Modula-3 verification condition generator, written initially 
by Damien Doligez and then mainly by Dave Detlefs. 
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